The present invention relates generally to data processing systems and, more particularly, to a file management process.
An operating system (OS) is the software responsible for controlling the allocation and usage of hardware resources such as memory, central processing unit time, disk space, and peripheral devices. The operating system is the foundation on which applications, such as databases, word-processing and spreadsheet programs depend. Popular operating systems include Windows, Windows NT and UNIX.
FIG. 1 shows a schematic block diagram of an exemplary prior art computer system 10, such as a Unisys server running a Master Control Program (MCP) operating system 12. Most operating systems include three (or more) different levels or layers in the I/O subsystem: the logical I/O level 14, the file system/directory level 16, and the physical I/O level 18. At the logical I/O level 14, an application program 20 interacts with the operating system to open, close, read and write files. The file system/directory level 16 handles the location of a given file within the file system, and the physical I/O level 18 level handles interaction with the actual hardware 22 of the computer system, such as a disk drive (not shown).
Many prior art computer systems, such as that illustrated in FIG. 1, support the notion of “file redirection.” One example of “redirection” is the manner in which files on different servers in a network are accessed by an application program running on a client computer. When the application program needs to open a file, it makes a standard call to logical I/O requesting that the file be opened. The application program uses the same interface to logical I/O regardless of whether the file exists on the same computer or a different computer across the network. If the file does not reside on the same computer, but rather exists on a different computer across the network, a redirector function at the file system level “redirects” the request to the computer on which the file is stored. See, for example, FIG. 1 wherein redirector 24 accesses remote server 26 via network 28. Conceptually, this process can be referred to as “redirection at the file system/directory level.” Redirection can also take place at the physical I/O level where, for example, a device driver might redirect certain file requests to different hardware devices.
FIG. 2 shows a schematic block diagram of the conventional prior art computer system 10 which illustrates the conventional method of file access via the logical I/O subsystem 14 of the Unisys Master Control Program (MCP) OS. When an application program 20 requests to open a file, the logical I/O subsystem 14 builds a file information block (FIB) 30 and provides the application program 20 with a pointer to the FIB 30. The FIB 30 is a container for information or attributes about a given file. For example, for disk files, the FIB 30 contains a pointer to a disk file header 32 for that file which is located in the file system/directory 16. The FIB 30 also contains pointers, or entry points, into routines within the logical I/O 14 that carry out the actual read and write operations on the file. There are different read( ) and write( ) routines within logical I/O 14 for different kinds of files.
Referring again to the disk file example, if, after opening a file, the application program 20 issues a READ request to logical I/O 14, the read( ) routine within logical I/O 14 to which the FIB entry points will execute. Next, that code makes the appropriate calls into the file system/directory 16 and the physical I/O 18 levels to read the requested file from the physical disk drive.
Various deficiencies exist with the conventional file access scheme, including the following deficiencies:
1. Absent additional programming, the system 10 can only access resource types that are supported by the native OS 12. If a different resource type needs to be supported, additional programming code can be written for the OS (including its device drivers), thereby increasing the size, cost and complexity of the OS. Writing and supporting such code may not be cost effective if the resource type is used by only one or a few users.
Alternatively, a hook may be inserted into the logical I/O 14 to gain access to the unsupported resource type. The MCP file subsystem has several implementations wherein logical I/O support has been moved out of the OS 12 and placed in external system libraries. These implementations typically support remote system file access. Keyed I/O and external I/O may also be handled in this manner. Hooks are placed in the logical I/O 14 to get in and out of the system libraries that provide the support for type of file to be processed. The use of hooks adds an additional level of complexity to the file access process.
2. I/O support implemented external to the OS is usually implemented using kernel mode/privileged libraries or device drivers. The programming required by such kernel mode components is often more difficult than application level programming and errors in kernel mode components are potentially destabilizing to the native OS 12.
Accordingly, there is an unmet need for a scheme that allows resource types to be accessed outside of the native OS, without adding code to the native OS, without using custom hooks added to the native OS, and in a manner that protects the stability of the native OS from errors in the code used for resource access. It would also be desirable to provide such a scheme which allows the logical I/O to use conventional I/O features or requests (e.g., OPEN, READ, WRITE, CLOSE) so that no changes have to be made to the logical I/O API used by application programs. The present invention fulfills such needs.